Several years ago, while I worked at a medium-sized university, there was a very similar incident like what happened in Student Is Sanctioned for Creating Class-Registration Web Site. A student wanted into a full class. So he built an application to routinely check for whether a seat was available in the Student Information System. The database administrator for the SIS noticed too much traffic from this user while looking into why the system was working too hard. My impression was the level of traffic was not at the Denial of Service level, but still something that needed to be addressed to improve the experience of others.
The CIO had a chat with the student. At the time it amused me because years before I had been in the same chair as the kid. After, the CIO joked about wondering whether to hire the student, the same as he had joked about me and a friend.
The student went on to develop a student organization site and other good things. He found the right outlet for him to express in code things to scratch his itches. Personally, I think this is good for the students and good for the university. However, a close eye needs to be kept on these students to ensure they make secure, stable, and long-term viable products. When the student graduates, there needs to be a plan for someone taking over the upkeep.
Since then, I have run across even professionals making these students’ mistakes of slamming a system with traffic. One administrator wanted to check whether we were up, so he wrote a JavaScript web page that would hit the development site we provided. It had one two machines, so when five people had that page open at the same time, they somehow got 4 on the same machine which croaked at that kind of load. Weblogic, in my experience, does not handle the same transaction for the same session when the first has not yet completed. Each subsequent transaction takes even longer than the first until it builds up to the point it is taking minutes to complete what should take a fraction of a second.
In general, developers will contact us about developing something to work against our system. We try to be helpful and advise what are likely successful directions. There are still mavericks, who will write something that causes a problem and we try to track down who it is slamming our systems. I consider it part of the job of running a system people want to use. Someone will try to accomplish things outside the normal enter a URL, type in a username, type in a password, click, click, click…. Heck, we write scripts to get around this.
These events are all opportunities to meeting and educating developers.
Leave a Reply