Content area
Digital repositories are still in nascent stages of development in academic institutions especially in developing countries like India. To identify the intellectual capital, facilitate knowledge sharing and management among the faculty and research staff at management institutions, the creation of digital institutional repositories is becoming a necessity. Management institutes in a developing country like India have constraints on infrastructure, manpower and funding. Thus identifying the resource requirements to establish an institutional knowledge repository keeping in view these constraints is necessary. The paper aims to describe a simulation on an institutional knowledge repository (IKR) test bed at a Business School using a performance and load testing tool to determine the number of simultaneous users that the IKR on a minimal server configuration can support on the institute intranet. An institutional knowledge repository (IKR) at ICFAI Business School, Ahmedabad, is built on a system with a minimal configuration using open source DSpace Institutional repository software to capture the intellectual capital and enable knowledge sharing. A simulation on the IKR test bed at ICFAI Business School, using a performance and load testing tool, to determine the number of simultaneous users that the IKR on a minimal server configuration could support on the institute intranet, is described. The simulation exercise helped determine that about ten-15 simultaneous users could be supported on the institute intranet in the current minimal configuration that the IKR test bed was built on. The simulation exercise when repeated with a server with higher memory indicated support for 15-20 simultaneous users. For institutions with less than 20 full time faculties and in the initial stages of IKR development this minimal system configuration was sufficient, though an IKR server with higher memory was recommended. Keeping in mind IT infrastructure constraints like disk space, memory and network in an academic institute; a minimal server configuration was chosen as the IKR Server and made available on the institute intranet as a part of the IKR test-bed for the simulation exercise. An IKR helps in capturing the intellectual capital and enabling knowledge sharing in a business school. An IKR can be initiated even with a minimal configuration at management institutes in a developing country like India. It is critical that business schools in India should identify the intellectual capital, facilitate knowledge sharing and management among the faculty and research staff, by initiating the creation of an institutional knowledge repository. A business school with a small number of faculties can initiate the process of setting up an institutional repository even with constraints of infrastructure, manpower and funding. The IKR is of value to the faculty and institution.
1. Introduction
Institutional repositories are digital collections capturing and preserving the intellectual output of a single or multi-university community ([1] Crow, 2002).
Institutional repositories are essential technologies for capturing structural intellectual capital, knowledge sharing and management in academic and research institutions, especially in developing countries like India. Institutional repositories may include pre-prints, technical reports, working papers, thesis and dissertations, conference proceedings, teaching materials etc ... the intellectual capital of the academic institution.
Open access digital repositories are still in nascent stages of development in India. The Directory of Open Access Repositories (Open DOAR) (www.opendoar.org/) lists only 27 digital repositories available for access in India as compared to 291 in the USA.
Academic institutes in a developing country like India, have constraints on infrastructure, manpower and funding. Thus identifying the resource requirements to establish an institutional knowledge repository keeping in view these constraints is necessary.
This paper presents a simulation done at a business school in India to determine the amount of data that could be supported and the number of simultaneous users who can search and view/access the contents of an institutional repository with a minimal server configuration.
2. Birth of the institutional knowledge repository
2.1 Need to capture the intellectual capital of a business school
The growing demand for professional managers resulted in the mushrooming of management education institutions across the Indian sub-continent. To evaluate the quality of education in these institutions various Business School Surveys are being conducted that rank these business schools in India.
These surveys depend on questionnaires filled up by the business schools. Most questionnaires taken into consideration parameters like brand value, learning ambience, intellectual capital and growth ([3] Doctor and Ramachandran, 2007a; [5] Doctor and Ramachandran, 2008a).
All the surveys give weightage and importance to the intellectual capital of the business school. A business school's intellectual capital is the sum of its human capital (talent- skills and knowledge of the people- faculty and students), structural capital (intellectual property - the published scholarly material of its faculty, methodologies, software, documents - technical reports, question banks and other knowledge objects) and customer capital (client relationships- students, corporate) ([8] Stewart, 2001). Thus, the capture and preservation of the published scholarly material of its faculty, the structural intellectual capital of a business school is important and is becoming a necessity for Indian business schools.
Many of the business schools find it difficult to collect data about the structural intellectual capital during the filling up of the questionnaires for the survey. The adoption of a technology like an institutional repository by the institutes would help store, retrieve and reuse this intellectual capital.
2.2 Enable knowledge sharing among faculties
A survey conducted among faculties in a business school, indicated a large number of new and inexperienced faculty. Availability of an institutional repository would encourage faculty to access scholarly materials which would provide an insight on the domain areas which faculty specialized in and be useful to the newer faculties. Knowledge sharing would thus be enabled ([4] Doctor and Ramachandran, 2007b).
2.3 Provide visibility to the intellectual capital of the business school and faculty
Institutional repositories enhance the visibility and prestige of not only the academic institute, but also the faculties of the academic institutions who contribute scholarly and research publications to the repository.
Once the institutional repository is open archive initiatives (OAI) (www.openarchives.org/) enabled, search engines can harvest its metadata and the Repository can be registered at directory open archives repositories (OpenDOAR) (www.opendoar.org/). The contents of the Institutional Repository would be visible worldwide, motivating faculty to deposit their scholarly materials.
3. The institutional knowledge repository
3.1 ICFAI Business School
ICFAI Business School (IBS) is a leading management institution in India offering a two-year full-time campus-based PG-DBA program. It caters to network of more than 6,000 students, 500 faculties across 18 centers geographically distributed across the country (www.ibsindia.org/). The centre's at Hyderabad, Kolkata and Bangalore have more than 40 full time faculties; centres at Mumbai, Gurgaon, Chennai, Ahmedabad, Pune have between 20 to 40 full time faculties and other centers less than 20 full time faculties. IBS represents a typical management institute setup, with different sized centres and constraints like infrastructure, manpower, funding.
The Outlook-Cfore Survey 2006 India's Top B-Schools ranks Icfai Business School, Hyderabad as one of the Top 10 Business Schools overall. Currently the "structural intellectual capital" at the Business School is being captured through paper forms called the Annual Research Reports which faculties are required to complete and submit. Creation of a pilot institutional repository at IBS Ahmedabad one of the centers of the IBS community was initiated to capture and maintain the structural intellectual capital; enable knowledge sharing and provides visibility to the intellectual capital of the faculty and business school.
3.2 Identifying requirements for a digital repository at IBS
Developing an institutional repository was possible only if faculties at IBS used digital resources for teaching and scholarly material and were ready to share these materials and contribute to the repository. A survey, to ascertain these details, was conducted. The survey revealed that faculty at IBS do use digital resources like PowerPoint, Word for scholarly publications and teaching material; they do indicate a knowledge sharing culture and tend to show a positive attitude towards the need and use of a digital institutional repository ([2] Doctor, 2008).
Another survey was conducted to ascertain different considerations for creating an institutional repository and its implementation experience as a tool to capture the structural intellectual capital and enable knowledge sharing. The survey revealed that faculties at IBS are aware of the e-resources and are using them for creation of their scholarly material. There is a positive trend in the usage of e-resources and a strong agreement for the availability of scholarly material on an institutional repository to share their knowledge and give visibility to their intellectual output. The survey showed that faculties indicated a preference to contribute published material like articles, journal papers and conference papers over material like teaching material, presentations and technical reports implying that the Institutional Knowledge Repository creation should be initiated with collecting articles, journal papers, conference papers and could be later on extended to teaching material and presentations. Considerations like the management and handling of the digital repository, motivational factors to contribute to the repository were also explored in the survey ([7] Doctor and Ramachandran, n.d.).
A study of the academic calendar of faculty at IBS Ahmedabad indicated that faculties are involved mainly with teaching, research activities and to some extent with other activities like organizing conferences, examinations, curriculum review etc. During teaching activities, the usage of Word and PPT documents was prominent, whereas during research activities, usage of Word and PDF documents was prominent.
3.3 Institutional knowledge repository (IKR@IBS Ahmedabad)
Keeping in mind infrastructure constraints, the institutional repository was installed on a machine available with a minimum configuration. The availability of open source software for creation of institutional repositories was a deciding factor for the pilot institutional repository.
The software's considered were the open source linux operating system, open source pre-requisites required for installation and open source DSpace digital repository system (www.dspace.org/). Technical knowledge of the vast array of software technologies required to set up and use the Institutional repository was necessary.
The pilot institutional knowledge repository, IKR @ IBS Ahmedabad installation is implemented using Fedora Core 4 Linux, Apache Tomcat 5.5.17, Apache Ant 1.6.5, J2EE 1.4 SDK Java platform, Postgres SQL 8.1.3, and DSpace Version 1.3.2. ([6] Doctor and Ramachandran, 2008b). A screenshot of the homepage of DSpace@IBS Ahmedabad is shown in Figure 1 [Figure omitted. See Article Image.].
The pilot institutional repository is OAI enabled and can be harvested by search engines. It is registered at DSpace Instances worldwide (http://wiki.dspace.org/index.php/DspaceInstances), Directory of Open Access Repositories (OpenDOAR), Cross Archive Search Services for Indian Repositories (CASSIR) (http://ardb4.ncsi.iisc.ernet.in/oai/) and is available at http://202.131.96.59:8080/dspace/.
Populating the pilot institutional repository was started with the scholarly published materials like articles, journal, conference papers and research reports. As educating the faculty with the use of DSpace software and promoting the use of the institutional repository has not yet been initiated in a systematic manner in this pilot testing; only a few faculties are self-archiving. The collections in DSpace@IBS Ahmedabad are slowing growing as can be seen in Figure 2 [Figure omitted. See Article Image.]. The collections are mainly Word, PDF and PPT files of different sizes ranging between 100 KB to 2.5 MB.
With the institutional repository slowly growing, in size (number of records) and usage (concurrent number of users) the need to know the amount of data that could be supported and the number of simultaneous users that the current minimal configuration would support, arose. Thus, a simulation was necessary to ascertain these requirements. Keeping in mind the number of full time faculty available at a business school, determining the number of simultaneous users that a given minimal server configuration of the institutional knowledge repository would support was necessary.
4. Simulation
In order to understand the resource requirements towards creation of IKR, a test bed was set up as a part of the simulation and analysis. Keeping in mind IT infrastructure resource constraints like disk space, memory and network in an academic institution; consciously; the IKR server in the test bed was installed on a minimal configuration of a Pentium IV @ 2.4 GHz with 256 MB RAM, 40 GB Hard disk.
In order to determine the amount of data that could be supported with a disk of 40 GB, it was noted that after installation of the Operating System, other pre-requisite Software's and DSpace resulted in the available disk space for data being approximately 30 GB. Allowing 5-10 GB of space for some indexes, backups implied that approximately 20-25 GB of space was available for data. The current data of 200 records available in the pilot institutional repository occupied only 0.7 GB. Using the export-import facility of the DSpace digital repository software, this data was repeatedly exported and imported into the repository. Approximately 4500 to 5000 records could be supported in 20-25 GB of space.
With network access being a constraint, the IKR was made available on the Institute Intranet @ 100 MBps for access by the full time faculties at the centre. The aim of the Simulation was to determine the number of simultaneous users that the Institutional Repository server could support on the Institute intranet. The simulation software considered for this exercise was Mercury Load Runner 8.0 (http://en.wikipedia.org/wiki/LoadRunner).
4.1 Load Runner
LoadRunner is a performance and load testing product by Hewlett-Packard (http://en.wikipedia.org/wiki/Hewlett-Packard) (since it acquired Mercury Interactive (http://en.wikipedia.org/wiki/Mercury_Interactive) in November 2006) for examining system behaviour and performance, while generating actual load. LoadRunner can emulate hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads, while collecting information from key infrastructure components (Web servers, database servers etc). The results can then be analysed in detail, to explore the reasons for particular behaviour.
Working in LoadRunner involves using three different tools, which are part of LoadRunner. They are Virtual User Generator (VuGen), Controller and Analysis.
The virtual user generator (VuGen) allows a user to record and/or script the test to be performed against the application under test, and enables the performance tester to play back and make modifications to the script as needed. The virtual user generator captures end-user business processes and creates an automated performance testing script, also known as a virtual user script. Once a script is prepared in VuGen, it is run via the controller. Each run is configured with a scenario, which describes which scripts will run, when they will run, how many virtual users will run. The controller organizes, drives, manages, and monitors the load test. LoadRunner uses monitors during a load test to monitor the performance of individual components under load. Once a scenario is set and the run is completed, the result of the scenario can be viewed via the analysis tool. This tool takes the completed scenario result and prepares the necessary graphs for the tester to view. Also, graphs can be merged to get a good picture of the performance. The tester can then make needed adjustments to the graph and prepare a LoadRunner report.
Load testing typically consists of five phases: planning, script creation, scenario definition, scenario execution, and results analysis as shown in Figure 3 [Figure omitted. See Article Image.].
4.2 Virtual user scripts
Files available in the institutional repository were being searched and viewed by the faculty. Every faculty or user would be searching and viewing a number of files of different sizes. Scripts were to be written which emulated this real user behaviour.
As a part of the simulation, dummy documents were uploaded in the institutional repository. Documents using three formats Word, PDF and PPT were created. A data set of six files of sizes 100KB, 500KB, 1 MB, 1.5 MB, 2 MB, 2.5 MB were created for all three formats Word, PDF, PPT. A user was made to search and view all six files of different sizes, of a document format sequentially. Scripts which emulated this user behaviour with the given data set were created using VuGen.
4.3 User scenarios
The institutional repository consisted of documents mainly in Word, PPT, PDF formats. Six typical user scenarios were considered, on the basis of the faculty usage of documents during the teaching, research and other activities. The six typical scenarios considered are as seen in Table I [Figure omitted. See Article Image.].
4.4 Data recording
Scripts, which emulated user behaviour with the given data set and user scenarios were considered for the simulation exercise. Varying the number of simultaneous users from 1 to 20, recordings of the transactions passed, transactions failed and time taken were noted. Think time considered was the recorded think time. For each Scenario, for varying simultaneous number of users, the average time taken, transactions passed and transactions failed of five runs were recorded. Recordings for Scenario 1 are shown in Table II [Figure omitted. See Article Image.]. Similar recordings were done for all the six scenarios, with varying number of simultaneous users, depicting the time taken, the transactions passed, the transactions failed and when the server hangs.
5. Data analysis
Resultant graphs for all the six scenarios, with varying number of simultaneous users, depicting the time taken, the transactions passed, the transactions failed and when the server hangs were generated.
Figure 4 [Figure omitted. See Article Image.] is a resultant graph of Scenario 1, where all users are searching only Word files. It can be observed that the server hangs when 18 simultaneous users are accessing the system.
Figure 5 [Figure omitted. See Article Image.] is a resultant graph of Scenario 2, where all users are searching only PDF files and Figure 6 [Figure omitted. See Article Image.] is a resultant graph of Scenario 3, where all users are searching only PPT files. In both the graphs, it can be observed that the server hangs when 19 simultaneous users are accessing the system.
The recording of the number of transactions that failed and when the server hangs are important parameters to determine the maximum number of simultaneous users that the system can support.
Figure 7 [Figure omitted. See Article Image.] is a summary graph of the recordings of the transactions failed and when the server hangs for Scenario 1, 2 and 3. It can be observed that the server hangs when 18 simultaneous users are accessing the repository and searching for Word files. The server hangs when 19 simultaneous users are accessing the repository and searching for PDF or PPT Files.
Thus, irrespective of the type of files being accessed, the institutional repository Server hangs with 18, 19 simultaneous users for the given data set of files.
The time taken, the transactions passed, the transactions failed and when the server hangs for Scenario 4 can be seen in Figure 8 [Figure omitted. See Article Image.]. In this case also, it can be observed that the server hangs when 18 simultaneous users are accessing the repository.
A resultant graph of the time taken, the transactions passed, transactions failed and when the server hangs for Scenario 5 can be seen in Figure 9 [Figure omitted. See Article Image.]. A resultant graph of the time taken, the transactions passed, transactions failed and when the server hangs for Scenario 6 can be seen in Figure 10 [Figure omitted. See Article Image.]. In these graphs, it can be observed that the server hangs when 20 simultaneous users are accessing the repository.
The recording of the number of transactions that failed and when the server hangs are important parameters to determine the maximum number of simultaneous users that the system can support.
Figure 11 [Figure omitted. See Article Image.] is a graph of the recordings of the transactions failed and when the server hangs for Scenario 4. The server is observed to hang when 18 simultaneous users are accessing the repository.
Figure 12 [Figure omitted. See Article Image.] is a summary graph of the recordings of the transactions failed and when the server hangs for Scenarios 5 and 6. The server is observed to hang when 20 simultaneous users are accessing the repository.
This simulation indicates, irrespective of the scenario being considered the institutional repository server cannot support 18 or more simultaneous users. It can be seen that when there are 10-15 simultaneous users, the number of transactions failed are approximately <5. Once the number of users is more than 15, the transactions failed increase rapidly and the server hangs around 18 users.
5.1 Data analysis with server memory 512 MB
As, the server was hanging with the current minimal configuration; the simulation experiment was repeated after upgrading the memory of the server to 512MB. The summary graph of the recordings of the transactions failed and when the server hangs for Scenarios 1,2,3 can be observed in Figure 13 [Figure omitted. See Article Image.]; Scenario 4 can be observed in Figure 14 [Figure omitted. See Article Image.] and Scenario 5, 6 can be observed in Figure 15 [Figure omitted. See Article Image.].
In all the three summary graphs it is observed that the server does not hang as the no of simultaneous users increase beyond 20 users. It can be seen that when there are 15-20 simultaneous users, the number of transactions failed are approximately <5. Once the number of users is more than 20, the transactions failed increase rapidly.
Conclusion
The simulation exercise helped determine that about 10-15 simultaneous users with transaction failures <5 and approx 4,500 to 5,000 records could be supported in the current configuration that the pilot institutional repository was built on. In the initial stages of the institutional repository development and the pilot testing, and for Institutions with less than 20 full time faculties, this configuration was sufficient.
The simulation exercise when repeated with a server with higher memory helped determine that about 15-20 simultaneous users with transaction failures <5 and approx 4,500 to 5,000 records could be supported. This institutional repository was sufficient for IBS Ahmedabad with approx 25 full time faculties.
With the growth of the institutional repository, in size (number of records) and usage (concurrent number of users) the need to support more data and users would arise. The repository access was initially limited to the intranet but could be expanded to internet access by faculty at other centres also. Of course, upgrading the available Repository from the intranet to internet would be a major decision as it would involve a high internet bandwidth.
Infrastructure like disk space, memory, network access etc, manpower and funding are always the initial bottlenecks in any implementation. In a developing country like India, especially in an academic institute, determining, justifying and sustaining requirements is an important aspect.
It is critical that business schools in India should identify the intellectual capital, facilitate knowledge sharing and management among the faculty and research staff, by initiating the creation of an institutional knowledge repository. A business school with a small number of faculties can initiate the process of setting up an institutional repository even with constraints of infrastructure, manpower and funding.
Proceedings of the International Conference on Future of Knowledge Organization in the Networked Environment, September 2007
Seventh IEEE International Conference on Advanced Learning Technologies, July, 2007
1. Crow, R. (2002), "The case for institutional repositories: a SPARC position paper", Scholarly Publishing and Academic Resources Coalition.
2. Doctor, G. (2008), "Capturing intellectual capital with an institutional repository at a business school in India", Library Hi Tech, Vol. 26 No. 1, pp. 110-25.
3. Doctor, G. and Ramachandran, S. (2007a), "Implementing an institutional repository for knowledge sharing", .
4. Doctor, G. and Ramachandran, S. (2007b), "Enabling knowledge sharing with an institutional repository", .
5. Doctor, G. and Ramachandran, S. (2008a), "Digital institutional repositories: capturing the intellectual capital of management institutions", Icfai Journal of Knowledge Management, forthcoming.
6. Doctor, G. and Ramachandran, S. (2008b), "DSpace@IBSA: knowledge sharing in a management institute", VINE: The journal of information and knowledge management systems, Vol. 38 No. 1, pp. 42-52.
7. Doctor, G. and Ramachandran, S. (n.d.), "Considerations for implementing an institutional repository at a business school in India", International Journal of Information Management, forthcoming.
8. Stewart, T.A. (2001), The Wealth of Knowledge Intellectual Capital and The Twenty First Century Organization, Nicholas Brealey, London.
About the author
Gayatri Doctor [Figure omitted. See Article Image.] is with the Information Technology & Systems Faculty at ICFAI Business School, Ahmedabad. She has 19 years of experience in industry and academics. Prior to ten years of experience in management teaching, she worked with WIPRO Information Technology. She holds a Master's degree in Computer Applications (MCA), MPhil in Information Technology and is currently pursuing her PhD. She has published articles in research journals of international repute namely: Elsevier's International Journal of Information Management , Emerald's VINE: The journal of information and knowledge management and Library Hi Tech . Her areas of interest are digital repositories and knowledge management.
Gayatri Doctor, ICFAI Business School, Ahmedabad, India
Gayatri Doctor
Figure 1: Homepage of the IKR @ IBS Ahmedabad
Figure 2: Growth of the repository
Figure 3: Load testing phases
Figure 4: Scenario 1 - only Word files
Figure 5: Scenario 2 - PDF files
Figure 6: Scenario 3 - only PPT files
Figure 7: Summary of Scenario 1, 2 and 3
Figure 8: Scenario 4 - Word-PDF-PPT (1-1-1) files
Figure 9: Scenario 5 - Word-PDT-PPT (2-2-1) files
Figure 10: Scenario 6 - Word-PPT-PDF (2-2-1) files
Figure 11: Scenario 4 transactions failed
Figure 12: Summary of Scenario 5 and 6 - transactions failed
Figure 13: Summary of Scenario 1,2 and 3 - transactions failed
Figure 14: Summary of Scenario 4 - transactions failed
Figure 15: Summary of Scenario 5 and 6 - transactions failed
Table I: Different scenarios
Table II: Recordings for Scenario 1 - only word files
Copyright Emerald Group Publishing Limited 2008